fix(tracing): drop the channel name type argument - #28

Closes #25.

Problem

src/tracing_channels.ts passed the channel name as the first type argument to
diagnostics_channel.tracingChannel. That matched @types/node v25, where the first parameter
was the unconstrained StoreType. In v26 the two parameters were swapped and the first one is
constrained to object:

// @types/node@25.9.4
function tracingChannel<StoreType = unknown, ContextType extends object = …>(…)

// @types/node@26.3.0
function tracingChannel<ContextType extends object = object, StoreType = ContextType>(…)

So a string literal no longer fits, and the published declarations of @boringnode/queue fail to
compile for any consumer on @types/node v26.

Change

The channel name is a runtime value, so the name type argument goes away and the message type
becomes the sole argument. On v25 it binds to StoreType and ContextType defaults from it; on
v26 it binds to ContextType and StoreType defaults from it. Both end up with the same pair:

declare const dispatchChannel: diagnostics_channel.TracingChannel<JobDispatchMessage, JobDispatchMessage>

The second commit widens the @types/node dev dependency to ^25.9.4 || ^26.0.0 so CI
typechecks against the major that exposed this — the previous pin could not resolve to v26, which
is why the repository never saw it. yarn typecheck, yarn lint and yarn format are clean with
v26 resolved (the two oxlint warnings in src/otel.ts and tests/sync_adapter.spec.ts are
pre-existing on main). Drop that commit if you would rather bump the range separately — the
first commit stands on its own.

Verification

Repository typecheck, with the dev dependency resolved to @types/node@26.3.0:

Consumer side, using the reproduction from the issue — npm pack of this branch installed in a
clean project with typescript@7.0.2, knex@3.1.0 and import { Job } from '@boringnode/queue':

No runtime change: the channel names, the published messages and the subscriber contract are
identical.